Medical multimedia database system

ABSTRACT

A medical image storage and retrieval system includes a database with relationally linked tables including a disease factoid table, an image and image caption table, and a patient data table. A flexible system allows for peer review, remote access and maintenance of the stored data, and query searching and retrieval of groups of related multimedia (image and text) case file information. The system facilitates distance learning and remote consultation.

STATEMENT OF GOVERNMENT RIGHTS

[0001] The Government has certain rights in this invention.

FIELD OF THE INVENTION

[0002] The invention relates generally to multimedia database systemsand in particular to a multimedia database system storing medicalimages.

BACKGROUND OF THE INVENTION

[0003] Over the past decade there has been a dramatic increase in thequality and types of imaging tools available to medical practitioners.There have also been significant advances in our ability to digitallycapture and store large data files, and a variety of attempts have beenmade to apply these new storage technologies to the proliferatingvolumes of medical images.

[0004] However, despite these recent advances there remains asignificant gap between a medical practitioner's ability to collectmultimedia information, and his or her ability to intelligently andefficiently use this information. In typical applications images arestored as part of a flat-file system, retrievable only when lateraccessing specific patient information. This amounts to little more thana digital version of the analog file systems of old. Where databaseshave been employed as something more than just enhanced filing systems,what is typically implemented is simple indexing around a title orspecialized code. Many of these systems are also confined to closednetworks. Where external access is available, little more than a staticdisplay is offered.

[0005] All of these approaches leave most of the promise of enhancedinformation-based productivity for the medical practitioner unfulfilled.There remains, therefore, a need for a system that is robust,interactive, and permits geographically remote practitioners to create,update, and relationally search multimedia medical information.

SUMMARY OF THE INVENTION

[0006] These and other problems are solved by the invention describedherein. In a present embodiment, a multimedia medical database includesa table space with multiple related tables, at least one of which storesmedical images. Thus, for example, in the MedPix™ product implementationof this embodiment, information is relationally stored in separatetables. These tables preferably include a disease information or“factoid” table, an image/caption table, and a patient/clinical datatable. Additional tables may also be used, for example, to store userprivileges, track student results, and capture expert information forgenerating specialized files like teaching files. This system can beused via any appropriate networking device, thus allowing for broadaccess. This permits a fully interactive product for storing,retrieving, and searching against a variety of medically relevantparameters. Since the tables and interfaces are dynamic and the databaseis relational, a robust information tool is now available to medicalprofessionals anywhere in the world with access to the Internet.Additionally, interactive diagnostic and teaching services may also beprovided, allowing multiple physicians to access and discuss multimediafiles, and allowing physician's a remote learning or expert platform bywhich interactive multimedia files may be created and the learningprocess facilitated via an automated program.

[0007] Still other and further aspects, advantages and embodiments ofthe present invention can be better understood in connection with thefollowing description and by reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008]FIG. 1 is a block diagram of an exemplary network-based multimediamedical database system in accordance with the present invention.

[0009]FIG. 2 is a logic flow diagram illustrating exemplary stepsemployed by a medical multimedia database system in accordance with thepresent invention.

[0010] FIGS. 3-11D are screen shots illustrating how information may bepresented and selected by a user in accordance with the embodiments ofFIG. 1 and 2, and in particular:

[0011]FIG. 3 illustrates a process for capturing case data;

[0012]FIG. 4 illustrates another process for building a new case file;

[0013] FIGS. 5A-5C illustrate processes for searching by category, imageor factoid information;

[0014]FIG. 6 illustrates an implementation for viewing returned imageinformation and for navigating between returned images;

[0015] FIGS. 7A-7B illustrate browsing windows for rapidly viewinginformation;

[0016] FIGS. 8A-8B illustrate a returned case file in a format thatincludes image and factoid information;

[0017] FIGS. 9A-9C illustrate another approach to searching, showing theresults for a search on physical location information, factoidinformation in response to a user selection, and image information inresponse to a further user selection, respectively;

[0018] FIGS. 10A-10B illustrate another approach to browsing, startingwith a glossary of key terms (FIG. 10A), and returned medicalinformation for browsing in response to a term selection (FIG. 10B);

[0019] FIGS. 11A-11D illustrate yet another approach to browsing,starting with an expandable glossary of anatomical terms (FIGS. 11A and11B), and returned medical information for browsing (FIGS. 11C and 11D).

DETAILED DESCRIPTION

[0020] Beginning with FIG. 1, a network environment for a multimediamedical database system is illustrated. In this system, a multimediadatabase 101 stores within its secure table spaces the component tablesin which the medical multimedia data is stored. These tables preferablyinclude a disease information or “factoid” table 102, a patient and/orclinical data table 104, and an image and/or caption table 106. Thesetables are relationally coupled via a program, typically via a DBMS 111(a “database management system” program), as will be described morefully below, but may otherwise be in any convenient format (includingrelational, object-oriented, object-relational, etc.). While oneimplementation of the invention has been developed in PostGres SQLlanguage using HTML, Java script, and PHP v.4 applications running on aLINUX operating system, those skilled in the art will appreciate thatthe invention may be readily implemented using a variety of databaseproducts, programming languages, browser interfaces, operating systems,and hardware platforms, depending on the preference of the developer andcharacteristics desired for a specific application.

[0021] In a current implementation, the multimedia medical database isaccessed via a network server 110, which is in turn connected to theInternet 115 via a network router 112. This conveniently allows users toaccess the database no matter where they are located, as long as theyhave access to a suitable interface device. When the user is merelyaccessing the system to view information, the device could be as thin asany hardware and/or software device with a Web-enabled browser,including, e.g., a personal digital assistant 124, a cell phone, orother wireless devices connecting via a wireless infrastructure 125 tothe Internet. To make full use of the multimedia database, however,devices such as desktop or laptop computers 120, 122 connected viabroadband or dial-up devices 121, 123 can be used. A skilled artisanwill appreciate that any one of a variety of devices and configurationscould be used in place of those described above. For example, in lieu ofserver 110 in a client-server architecture, a mainframe, local computer,or any convenient processor and memory combination that is capable ofstoring the database 101 and accessing/manipulating the table, securityand other information, may be used. Similarly, the connection could bevia any electromagnetic interface (bridges, infrared links, local andoptical networks), not just a router based wide area network, and anyconvenient input device capable of inputting or outputting via theinterface to the database may be used.

[0022] Turning now to FIG. 2, an overview of the multimedia medicaldatabase's functionality is provided from the user's perspective. In thepreferred system implementation, the first user step will be an accesslogon (step 201). This typically includes a user presentation of theirsystem name and a password, although additional levels of security andaccess control schemes may be used where more sensitive information isbeing stored. Thus, multiple levels of privileges may be supported, suchas for an author of a file, a reviewer, an editor, a guest, and a systemadministrator. The level of privileges may also vary based upon thestate of the file and the particular information being manipulated. Forexample, where a user with author privileges has the full ability tocreate a new file, certain fields (such as factoid categories) in thefile may still be locked against subsequent changes by the author afterthe file has been approved by an editor. Similarly, an author may nothave privileges to edit modifications like reviewer comments. Moreover,multi-level access control, using role-based or other schemes, may beadvantageously employed. Which approach to adopt is a matter of designchoice that one skilled in the art would understand how to implement.When using a multi-level system, e.g., the same registered user could bequalified for all five types of privileges, with the particularprivilege being determined based upon the file or information within thefile that is being accessed. Thus, even though a person acted as bothauthor and editor of a given file, it is possible that after approval hecould be restricted to visitor status with respect to certain fileaccess, and may lack even these privileges with respect to portions ofthe file (e.g., sensitive patient information, where his role haschanged vis-à-vis the patient's care). Such versatility can be veryhandy when dealing with sensitive information, but this must be balancedagainst the complexity of administering multilevel access.

[0023] Once a user is registered with the system, he or she proceeds toselect the particular process that they want to use (step 205). For manyusers, the most common processes will be browsing or searching throughcase files (step 250), or adding new cases to the database (step 210).In addition to these two processes, some of the users will be accessingthe editor routine (step 220), working with teaching files (step 240),or other specialized review processes such as the consultation processof step 230. The system may also be designed to mask those processes, oroptions within a given process, for which a user does not havesufficient privileges.

[0024] When a user wants to create a new case, he or she begins byselecting the new-case creation process (step 210). In a preferredsystem, this data entry process is streamlined, and the user is onlypresented with data entry options tailored to the type of information heor she is most likely to enter. This may be accomplished by firstprompting the user to select the type of data that she wishes to enter.Thus, while users may generally be encouraged to enter as much data asthey feel appropriate, if all they want to enter for a particular caseis image/caption data, they may conveniently accomplish this by clickingor selecting, or using other interactive means, an image/caption entry,following which the system returns a more tailored data-entry interface.

[0025] The system may also be designed to be responsive to pre-storedinformation concerning the registered user. In that case, a narrower setof options and data-entry interfaces tailored to the medical practicefield of the user may be presented. In doing so, the system streamlinesthe process as much as possible for doctors of a given specialty. Thishas the benefit of not only saving the doctors time in the data-entrystage, but by narrowing the options to those relevant to their specialtyand removing confusing clutter from the entry process, an improvedquality can also be achieved for the data being entered.

[0026] A current implementation for use in capturing case data isillustrated in FIG. 3. This figure shows a Web browser-enabled dataentry interface, via which any user having a web browser can communicatedata with the database. In the illustrated case, a user begins withselection of a factoid entry option. In response, the system returnsappropriate HTML pages as data-entry interfaces. The entry of textdescribing the disease or condition information is thus possible, forexample, via Text Entry Box 301.

[0027] A variety of other data-capture tools may also be presented. Ifthe user is a radiologist, a pull-down menu may be used to help themrapidly select appropriate ACR radiology codes. By hierarchicallylinking the data available for the pull-down menus, a user can rapidlyprogress from general systems down to the unique name or codeidentifying the particular condition or disease. Other well-known codes,such as the ICD codes, may be used as appropriate. A user community mayalso find it convenient to implement a more generic coding system, suchas the MedPix codes block that is illustrated in connection with FIG. 3.In developing such coding schemes, it is useful to allow certain usersto have privileges to add new entries to the pull-down lists, such asthe Add New Category box 305 for MedPix codes 303. Thus, throughinteraction with the broader user community, a more tailoredhierarchical coding structure can be rapidly developed for thatcommunity.

[0028] Any other desirable information relating to the disease orcondition should also be prompted for user input at this point. Suchinformation could include a descriptive title for the factoid, thenarrative entry described above, keywords associated with theinformation being entered, system and location information (organ, bodypart), or other category information (e.g., type of disease). In a morerobust system, the fixed-entry items such as the pull-down menus andcodes will also be processed against appropriate expert rules, so that auser can be prompted during the data-entry stage to change entries thatappear to be in conflict or otherwise trigger a rule violation. Finally,once a user is finished entering the factoid information, she need onlyclick on the Submit button for the data to be forwarded for entry to themultimedia database management system.

[0029] If all that the user wanted to enter was factoid information, theuser could exit the system at this point. However, for a complete casethe user would want to proceed and enter the patient and imageinformation also. For a typical user this can be convenientlyaccomplished by including all the appropriate entry fields and promptson the same new case-creation screen. The user would then proceed toenter image information (step 214) by scrolling down and selecting orinputting appropriate caption information, and uploading an image filefrom their location to the database. To simplify the user's process ofinputting this information a wide variety of media formats may beaccepted. However, the multimedia database system preferably includesappropriate image converters for resizing or formatting the image intoone of a selected group of formats for consistency. It is also desirablefor the system to have the capability of automatically generatingthumbnail images at this point, making subsequent display and browsingmore convenient for users. All of this information would typically bestored in the same record in the image table, and appropriately relatedto the other tables of the multimedia database (e.g., the factoid andpatient tables).

[0030] Finally, a user can also input relevant patient and clinical dataat the same time the factoid and image data are entered. Thisinformation could include, e.g., demographic information, history, othertreatments, and the like. To the extent private or other sensitiveinformation is added, the user may also be granted the option of settinghigher access restrictions regarding who can view the information (step216). Once all the desired information has been added, the user submitsit for appropriate processing and posting.

[0031] While this new file creation process has been described inconnection with a browser-enabled system, those of skill in the art willappreciate that any one of a variety of data-entry systems may beutilized. Thus, proprietary templates or non-browser enabled accessscreens can be used, e.g., as may be found in connection with manydatabase systems. But, in addition to systems oriented around keyboardsand mice, appropriately configured touch-screen systems (like PDAs), oreven voice-recognition enabled systems may be used as part of thedata-entry interface to the user. Moreover, while the multimedia medicaldatabase has been particularly described in connection with the storageand use of image data, a skilled artisan will readily appreciate how thesystem may be used with any appropriate form of non-text data. Forexample, audio information, audio-visual information, or other capturedelectromagnetic information from medical instrumentation, or the like,may be stored as part of the captioned image (multimedia) table record,and accessed by users with appropriately configured interfaces.Accordingly, in the context of the present application, the term ‘image’should be read as representative of all non-textual multimediainformation, and not just restrictively in the sense of non-alphanumericvisual representations or objects.

[0032] In a preferred system, each image/caption record will have bothmandatory and optional descriptors. The mandatory descriptors should bechosen so as to facilitate subsequent viewing and data mining, and canvary by medical specialty. Some useful types of descriptors include: theimage plane (e.g., coronal, sagittal, etc.), image type (e.g., MR, CT,surgical, clinical, etc.), ACR code, MedPix (or other proprietary) code,image source and creation information, copyright/privacy restrictions,and the like. During the case creation process, this image/captioninformation is relationally cross-linked to the factoid and/or patientprofile table information, to the extent such additional information isentered for a given case. In addition to the images that are stored aspart of the record, the system may also be implemented so as to archivea copy of each image as originally uploaded by the author (including theoriginal file name if desired).

[0033] Similarly to the process with image/caption tables, mandatory andoptional fields may also be employed with the factoid and patienttables. Examples of some of the mandatory fields that could be employedwith a factoid include: the title, an ACR code, the location/organsystem, the disease category, and the factoid text. If the user hasstarted to create a case, but does not have all the mandatoryinformation or for some other reason is not yet prepared to submit acase, the system may also include a temporary storage feature by whichan author can save a partially completed case and finish its completionat a later time.

[0034] Once a new case has been entered, it is automatically placed inan electronic submissions bin, along with other new cases, for editorialreview. While this editorial process may not be required in allimplementations, it does help enforce a higher standard of quality andintegrity for the data being made available to the practitioners usingthe system. This editorial review process typically begins by anautomated assignment of a new case file to an editor who is authorizedto review that type of case. The editorial selection can be based on anyconvenient category, such as the MedPix or ACR codes, organ/locationinformation, patient or image type, etc. In lieu of assigning specificeditors, all or a portion of the new cases may be available for anyonewithin a group of editors to select. The type of assignment processchosen is largely a matter of convenience for the editors, balancedagainst the need for timely review of the new submissions being held orotherwise tagged for restricted access pending editorial review.

[0035] The next step in the editorial review process (step 220) maycommence at any time an assigned editor is connected to the system. Theeditor can be prompted via any appropriate push technology (like e-mail,screen alerts, pages sent by the review module) that new submissions arewaiting for his review, or the editor can initiate a review via a buttonor other appropriate prompt to access a review menu. Once the reviewprocess has begun and a particular file is open, the editor proceeds toreview it for accuracy, and is able to modify most of the fileinformation as needed (steps 222-226). After his review is over, theeditor approves and closes the file, at which point the systemautomatically updates the file and makes it available to authorizedsystem users (step 228).

[0036] Any time a file is altered outside of the editorial reviewprocess, it is preferable to have it automatically returned to theelectronic submissions bin for further review. On the other hand, inappropriate circumstances the editorial review process may be modifiedor bypassed. For example, it may be desirable to permit submissions byspecially qualified editors, or even peer-level systems administratorsperforming batch uploads of pre-qualified information, so cases can beimmediately released without the delay of the typical editorial reviewprocess.

[0037] Another circumstance in which case information may be madeavailable to other users prior to an editorial review is illustrated inconnection with steps 230-236. These steps illustrate a consultationprocess by which the multimedia medical database can be used for live orcontemporaneous consultations. When entering this mode, the physiciancreating the new case can be given the option to tag it for immediatereview by consulting physicians. This process may be facilitated by thesystem allowing the case author to grant limited review and/or editprivileges to other system users designated by the author. One way ofaccomplishing this is allowing the author to solicit interestedphysicians, for example by e-mail, browser, or other suitable alert.While the author can generate e-mails on his own to physicians with whomhe has an established relationship, the multimedia database system mayoptionally provide an automated solicitation service (by e-mail, webbrowser alerts, or the like) to other registered users of the system.

[0038] Once another physician has responded to the request for consultservices, she need only log on to the system and retrieve the designatedcase for which the author has extended consult privileges.Alternatively, the first physician could provide a password or otheraccess criteria (including but not limited to a name, certificate, orverified id) for the consulting physician to use when accessing thefile.

[0039] At this point, both physicians may contemporaneously (i.e.,within minutes or hours, if not seconds, of each other) or evensimultaneously review the same case information. If desirable, thephysicians can enter a chat (voice, text, or graphics) mode, entercomments on the file, or otherwise edit the data. An appropriatelyconfigured system (e.g., with Internet telephony capabilities) may evenallow voice or multimedia conferencing between the physicians while theyare at their computer or network terminals (step 234). Specialdiagnostic, prescriptive, or other information can be stored in theprivate patient table fields (step 235). As part of the consultationprocess, one or both physicians may also conduct simultaneous searcheswithin the multimedia medical database for pertinent informationrelating to the consult. Finally, once the consult is over, the authormay select to submit the case file for further processing and posting,as described above in connection with a typical new case creationprocess (step 236). Steps 240-247 illustrate yet another interactiveprocess for use with the multimedia medical database. This process isparticularly advantageous for use in connection with interactivepresentations or teaching events. The author begins by initiating a casebuilder for use with the presentation (step 240). This may be similar tothe process for building a new case, as is illustrated by FIG. 4. Ifavailable and convenient, pre-existing case information can be reusedand edited; otherwise, an entirely new case may be built (step 241). Ifpre-selected data is used, the author can edit this data within thecontext of the teaching file to better tailor it for its teachingpurposes. The system also, preferably, provides the author with asimplified process by which the selection, modification, specialquestions, special presentation features, and results are captured.Thus, a user-friendly template can be provided for users who are nototherwise familiar with, e.g., HTML document authoring. This templatewould be prepared in a manner to prompt a user to input desired text andimage information, presentation information, user information and thelike, and an application for taking the user inputs together withpredefined information (such as formatting, privileges, etc.) to createan end-product. This helps expedite the process of inserting theinstructions and questions wanted for presentation to theaudience/students, determining any special ordering in which theinformation is presented, and providing the links, e.g., to securefile(s) for storage for the interactive responses. By way ofillustration, in a typical case a teaching physician may start byselecting a known case having interesting factoid and clinicalinformation, along with selected images. If the goal of the presentationis to test knowledge relating to the images, the author would modify ordelete unnecessary clinical information, adjust the factoid informationas appropriate, and add additional images that are not accuratelyrelated to the described factoid. This file is then stored (step 242)for later retrieval by the student (step 245). When reviewing the file,the student would be presented with the appropriate instructions,factoid, clinical, and image information pre-selected by the teachingphysician. As the student selects the image that she thinks is correct,the result is captured in a report file/table. The correct answer isalso displayed at that time (step 246-247).

[0040] While the teaching case builder has been discussed in connectionwith a simple test involving the selection of correct images, thoseskilled in the art will readily appreciate its versatility for use intesting almost any information related to a case. Thus, for example, theauthor could just as easily have presented complete image information,but omitted certain clinical or factoid information and asked thestudent to select or fill-in what she believes is the correctinformation. Further, where a series of cases have been designed into amodule, an expert system can be advantageously used-such as systemswhich those skilled in the art will readily recognize as being used inconnection with edutainment software programs-to select subsequent casesbased upon the student's responses to earlier ones. Thus, if the studenthas correctly answered one or more of a class of questions, the programcould automatically select a subclass or altogether different class(e.g., making the testing harder, or moving onto other subject matterareas). Further, its utility beyond simple testing should also beapparent. It can, for example, be readily adapted to facilitateinteractive continuing education to medical professionals, with theanswers being provided to the professional taking the teaching module(i.e., sequence of cases) and, if desirable, to other interestedentities (certifying boards, local hospitals, payor entities and thelike).

[0041] Turning now to steps 250-268, a process for viewing stored casesis illustrated. This process begins at step 250, with the registereduser selecting the View or Search option. The user can start this eitherat his initial logon, or can alternatively link to this view mode byselecting an appropriate button available within one of the other systemwindows. FIG. 5 illustrates one possible search entry window (step 255).As a matter of convenience to the user, a selection of possible searchcategories is presented at the top of the page, FIG. 5A. FIGS. 5B and 5Cillustrate a range of options available when searching by images orfactoid information. Because of the relational nature of the caseinformation stored in the tables of the multimedia medical database, avariety of search criteria from one or more of the available tablefields can be used in developing a search as broad or as narrow as theuser desires. Thus, a user may search for all cases in which the wordsbrain and tumor appear in the image captions, or may further limit it bytopical or text information from the factoid tables. More advanced userscan design their own search criteria by, e.g., writing their own Booleansearch script.

[0042] Once a query has been entered, the user next selects files forviewing from the retrieved results (steps 260-265). FIG. 6 illustratesone implementation for viewing returned image information via a casenavigator. Tools such as buttons for previous and next images, andpull-down menus for moving between images, may be used to assist thedoctor in moving between the retrieved files. FIG. 7 illustrates analternative implementation in which conditional information like codesand non-private patient information are displayed for rapid browsing ofthe returned results, along with appropriate links to additionalinformation. FIGS. 8A and 8B illustrate a returned case file in a formatthat includes image and factoid information. The buttons on this pagealso illustrate the versatility that can be added via a multimediamedical database system. For example, a user can choose to continue hissearch through links back to internal search interfaces, or throughlinks out to external search facilities (buttons 801-803). A userinterested in building another case can use the link via button 804 tostart building such a case. A user with appropriate authorization canedit the window or add images via buttons 805 and 806. Reviews orcomments can also be added via button 807. FIG. 9 illustrates yetanother approach towards the return of search results. In this case,FIG. 9A shows a search performed around location information (theendocrine/thyroid). In response to a user's view selection (or editselection, if authorized), a selected factoid is returned, as shown byFIG. 9B. In further response to the selection by the user of an imagethumbnail 902, the image of FIG. 9C is then displayed.

[0043] As FIGS. 5 through 9 illustrate, a user can rapidly search andnavigate through a large database of images and information using thepresent invention. Several implementations for how such a search can bedone within a browser-enabled environment have been illustrated, but oneskilled in the art will readily understand how to more broadly ornarrowly enable searches based on the preferences of the usercommunities involved. One such additional approach is illustrated inconnection with FIGS. 10 and 11, which illustrate the browse modes ofstep 252 and 254. Starting with FIG. 10A, a glossary of keywords andtitles can be built. This information is preferably captured via the useof pull-down menus or other fixed lists presented at the time case filesare entered. Using such a glossary, a user can scroll down and selectthe glossary term of interest, which in the illustrated case of FIG. 10Bis the adrenal gland. While a glossary file is likely to be more genericin scope, it will contain links to related information such as theillustrated location code (which can be used in further searching) andlinks to external URLs. One can also use the Case Builder button in theprocess of building a new case.

[0044]FIG. 11 illustrates yet a different approach to browsing. Startingwith FIG. 11A, a listing of potential criteria (anatomic locations) forselection by the user is displayed in response to the user's selectionof browsing factoids by anatomic location. Using any of the well-knownprocesses for expanding HTML-based lists, FIG. 11B illustrates how themulti-system location entry has been expanded to display possibleselections within that category. After a user selects the Angiogenesisbutton, a listing of the angiogenesis factoids is returned. In theillustrated case, where there is only one factoid, a single case filemay be returned, such as is further shown in FIGS. 11C and 11D.Alternatively, a listing of files substantially matching thesearch/browse criteria may be returned containing summary information(such as a title or caption), from which the user may then select anindividual case file. Once the individual file is returned, the user isable to view and make authorized edits, and link to other pages orsites, as he or she might from any typical displayed case screen.

[0045] In conclusion, what has been disclosed is a new medicalmultimedia database system. The database includes relationally linkeddisease or factoid information, image/caption, and patient/conditiontables, respectively, which in operation store disease/factoid data,image/caption (or other multimedia) data, and patient/condition data,respectively. Because of the relational linkages, part or all of theinformation from any given case, which is stored in related records inthe different tables, can be returned in a variety of formats, dependingon factors such as the context and privileges of the user. The methodsand apparatus of this system can be implemented to allow simple entryand searching for relative novices, but also be scaled upwards to usablystore vast amounts of information and allow for complex searches andre-uses of case information. Some of the somewhat more complexapplications have been touched on in the examples of interactivelearning and remote consultation described above.

[0046] In the current implementation of this system, an apparatus andmethod for a medical multimedia database system comprises (a) a diseaseinformation table which is operable to store plural disease factoidfiles; (b) an image table which is operable to store plural image fileseach comprising at least image and image caption information; (c) apatient data table which is operable to store plural patient files eachcomprising one or more patient and clinical data items; (d) where thefactoid, image and patient tables are operably coupled such that relatedfactoids, images, and patient data are relationally linked to each otheras a case files. This relational coupling can take any desirable form,e.g., from a simple relating of one image record to one factoid recordto one patient record, to a relating of one factoid record to amultitude of image records, to a complex matrix of cross-related image,factoid and patient records. This system further comprises: remote userinput of case files; a verification process limiting access to new casefiles until approved by peer reviewers; a peer review process wherebyusers with comment privileges can append comment data to a case file;enhanced case files, comprising simple and complex relationships,including a linking of related case files by specified components (e.g.,the same patient file linked to multiple factoid/image files);interactive training systems for selectively displaying case fileinformation, further linked to a training table including experttraining file information interactively responsive to user-selectedinputs, and also linked to a training table for storing student results;a consultative program system for selectively presenting case fileinformation for contemporaneous or real-time review of multimediamedical case files; and privacy and access limitation features. Theprivacy and access features are preferably implemented via an accesscontrol module; the search and browse features are preferablyimplemented via a search module of the DBMS 111; and the learning (filebuilder and presentation), consultation, expert, and reviewer featuresare preferably implemented via learning file builder, presentation,consultation, expert and review modules, respectively. These modules maybe separate and even remote programs, or integrated (partially orwholly) together with the medical multimedia database program, dependingon the design choices of those skilled in the art implementing thesystem.

[0047] It is believed that the operation and construction of the presentinvention will be apparent from the foregoing description. While themethod, apparatus and system shown and described has been characterizedas being preferred, it will be readily apparent that various changes andmodifications could be made therein without departing from the scope ofthe invention, and that the invention is not limited to theseembodiments. For example, those skilled in the art will appreciate howeach of the elements of the aforementioned embodiments may be utilizedalone or in combination with elements of the other embodiments. Theseand further modifications may be made by those skilled in the art,particularly in light of the foregoing teachings, without departing fromthe scope of the invention.

We claim:
 1. A medical image database system having plural tablescomprising: a. a disease information table, operable to store pluraldisease factoid files; b. an image table, operable to store plural imagefiles each comprising at least one of an image and image captioninformation; c. a patient data table, operable to store plural patientfiles each comprising at least one of patient information and clinicalinformation; wherein the disease information, image, and patient datatables are operably coupled such that a related first factoid file, afirst image file and a first patient file are relationally linked toeach other as a first case file.
 2. The system of claim 1, furthercomprising: d. a security module, operable to determine a user's accessprivileges to the tables; e. a new file creation module, operablycoupled to the tables for adding a new case file including factoid,image and patient data in response to a user input; and f. a reviewmodule, operably coupled to the tables and the security module, andoperable to provide new case files to at least one reviewer to reviewthe content of the new case file, to receive one or more modificationsfrom the reviewer and apply said modifications to the new case file, andto receive an approval indication from the reviewer and operate togetherwith the security module to change one or more access privileges of thenew case file.
 3. The system of claim 1, further comprising: d. asecurity module, operable to determine a user's access privileges to thetables; e. a new file creation module, operably coupled to the tablesfor adding a new patient case file including factoid, image and patientdata in response to a first user's inputs, the inputs also including acriterion for access to the patient case file by additional users; andf. a review module, operably coupled to the tables and the securitymodule, and operable to provide the new patient case file to at leastone further user of the additional users to review the content of thepatient case file, to receive one or more modifications from saidfurther user and apply said modifications to the patient case file. 4.The system of claim 3, further comprising: g. a consultation module,operably coupled to the review module and operable to providecontemporaneous access to the new patient case file to the first userand said further user and contemporaneous communications between thefirst user and said further user relating to the new patient case file.5. The system of claim 4, further comprising: h. a search module,operably coupled to the tables and operable to return to the furtheruser, substantially contemporaneous with said access to the consultationmodule, case file information from at least one of the diseaseinformation, image, and patient data tables, in response to searchcriteria related to the new patient case file.
 6. The system of claim 5,wherein the review module further comprises logic to provide the newpatient case file to a reviewer to review the content of the new patientcase file, to receive modifications from the reviewer and apply saidmodifications to the new case file, and to receive an approvalindication from the reviewer and operate together with the securitymodule to change one or more access privileges of the new patient casefile.
 7. The system of claim 1, further comprising: d. a new patientfile creation module, operably coupled to the tables for adding a newpatient case file including factoid, image and patient data in responseto a user input; and e. an expert module, operably coupled to the tablesand new patient file creation module, and operable to (i) provideselection criteria to the user for searching for files havinginformation related to the new patient case file, (ii) processingselection criterion received from the user, (iii) returning to the usercase file information matching said selection criterion, and (iv)performing steps (i) through (iii) for additional selection criteria,wherein the expert module narrows the matching case file informationreturned to the user to assist the user in a diagnosis relating to thenew patient case file.
 8. The system of claim 1, further comprising: d.a new case file creation module, operably coupled to the tables foradding a new case file in response to a user input; e. an educationalfile builder module, operably coupled to the tables and new case filecreation module, and operable to (i) provide selection criteria to theuser for designing an educational file based in part on the new casefile; and (ii) processing selection criterion received from the user,including at least one of inaccurate information added to or omittedinformation withheld from the educational file, an answer prompt, and acorrect answer to the answer prompt, so as to build and store theeducational file; and f. a presentation module, operable to (i) presentthe educational file to a further user; (ii) capturing an answer inputin response to the answer prompt; and (iii) returning the correct answerto the further user.
 9. The system of claim 8, wherein the educationalfile builder module further comprises logic for creating a sequence ofrelated educational files, and the presentation module further compriseslogic for presenting at least part of said sequence of relatededucational files.
 10. The system of claim 9, further comprising: g. anexpert module, operably coupled to the tables and presentation module,and operable to (i) determining an accuracy level of answer inputs forsaid at least part of said sequence of related educational files, and(ii) determining a next educational file to present to the further userbased in part on said determined accuracy level.
 11. The system of claim9, wherein the further user is a medical student and the presentationmodule further comprises logic for capturing answer inputs by themedical student for each of the sequence of related educational filesand storing a representation of the captured answer inputs forsubsequent use by an educator.
 12. The system of claim 1, furthercomprising: d. a search module, operably coupled to the tables, andoperable to accept user inputs representative of a search criterion andto return to the user a list representative of the accessible case filessubstantially matching the search criterion.
 13. The system of claim 12,wherein the search module further comprises browsing logic operable, inresponse to user selection of a category, to return a list of each casefile for which the search criterion substantially matches data containedin such case file's factoid, image and patient data.
 14. The system ofclaim 12, wherein the search module further comprises search logicoperable, in response to user selection of medical information tosearch, to return a list of each case file for which the medicalinformation substantially matches data contained in such case file'sfactoid, image and patient data.
 15. A medical image database programcomprising: a. plural tables, comprising (i) a disease informationtable, operable to store plural disease factoid files, (ii) an imagetable, operable to store plural image files each comprising at least oneof an image and image caption information, and (iii) a patient datatable, operable to store plural patient files each comprising at leastone of patient information and clinical information; wherein the diseaseinformation, image, and patient data tables are operably coupled suchthat a related first factoid file, a first image file and a firstpatient file are relationally linked to each other as a first case file;b. a security module, operable to determine a user's access privilegesto each of the tables; c. a new file creation module, operably coupledto the tables for adding a new case file including factoid, image andpatient data in response to a user input; d. a review module, operablycoupled to the tables and the security module, and operable to providenew case files to at least one reviewer to review the content of the newcase file, to receive one or more modifications from the reviewer andapply said modifications to the new case file, and to receive anapproval indication from the reviewer and operate together with thesecurity module to change one or more access privileges of the new casefile; and e. a search module, operably coupled to the tables, andoperable to accept user inputs representative of a search criterion andto return to the user a list representative of the accessible case filessubstantially matching the search criterion.
 16. A medical imagedatabase system comprising: a. plural tables, comprising (i) a diseaseinformation table, operable to store plural disease factoid files, (ii)an image table, operable to store plural image files each comprising atleast one of an image and image caption information, and (iii) a patientdata table, operable to store plural patient files each comprising atleast one of patient information and clinical information; wherein thedisease information, image, and patient data tables are operably coupledsuch that a related first factoid file, a first image file and a firstpatient file are relationally linked to each other as a first case file;b. a security module, operable to determine a user's access privilegesto the tables; c. a new file creation module, operably coupled to thetables for adding a new patient case file including factoid, image andpatient data in response to a first user's inputs, the inputs alsoincluding a criterion for access to the patient case file by additionalusers; d. a consultation module, operably coupled to the security moduleand operable to provide contemporaneous access to the new patient casefile to the first user and at least one further user of the additionalusers to review the content of the new patient case file; and e. asearch module, operably coupled to the tables and operable to return tothe further user, substantially contemporaneous with said access to theconsultation module, case file information from at least one of thedisease information, image, and patient data tables, in response tosearch criteria related to the patient case file.
 17. A medical imagedatabase system comprising: a. plural tables, comprising (i) a diseaseinformation table, operable to store plural disease factoid files, (ii)an image table, operable to store plural image files each comprising atleast one of an image and image caption information, and (iii) a patientdata table, operable to store plural patient files each comprising atleast one of patient information and clinical information; wherein thedisease information, image, and patient data tables are operably coupledsuch that a related first factoid file, a first image file and a firstpatient file are relationally linked to each other as a first case file;b. a new case file creation module, operably coupled to the tables foradding a new case file in response to a user input; c. an educationalfile builder module, operably coupled to the tables and new case filecreation module, and operable to (i) provide selection criteria to theuser for designing an educational file based in part on the new casefile; and (ii) processing selection criterion received from the user,including at least one of inaccurate information added to or omittedinformation withheld from the educational file, an answer prompt, and acorrect answer to the answer prompt, so as to build and store theeducational file; and d. a presentation module, operable to (i) presentthe educational file to a further user; (ii) capturing an answer inputin response to the answer prompt; and (iii) returning the correct answerto the further user; wherein the educational file builder module furthercomprises logic for creating a sequence of related educational files,and the presentation module further comprises logic for presenting atleast part of said sequence of related educational files; and whereinthe further user is a medical student and the presentation modulefurther comprises logic for capturing answer inputs by the medicalstudent for each of the sequence of related educational files andstoring a representation of the captured answer inputs for subsequentuse by an educator.
 18. A method for providing remotely accessiblemedical image database information via a medical image database havingplural tables, comprising: a. storing plural disease factoid files in adisease information table; b. storing plural image files each comprisingat least one of an image and image caption information in an imagetable; c. storing plural patient files each comprising at least one ofpatient information and clinical information in a patient data table;and d. operably coupling the disease information, image, and patientdata tables such that an at least one factoid file, at least one imagefile and at least one patient file are relationally linked to each otheras a first case file.
 19. The method of claim 18 further comprising: e.adding a new case file including factoid, image and patient data to thetables in response to a user input and associating a first accessprivilege with the new case file; f. providing the new case file to atleast one reviewer to review the content of the new case file; and g.receiving from the reviewer (i) one or more modifications from thereviewer and applying said modifications to the new case file, and (ii)an approval indication and associating a second access privilege withthe new case file.
 20. The method of claim 18 further comprising: e.adding a new patient case file including factoid, image and patient datato the tables in response to a first user's inputs, the inputs alsoincluding a criterion for accessing the patient case file; f. verifyingthat an additional user has access privileges matching the criterion foraccessing the patient case file, and providing the new patient case fileto the additional user to review the content of the patient case file;and g. receiving one or more modifications from said additional user andapplying said modifications to the patient case file.
 21. The method ofclaim 20 further comprising: h. providing contemporaneous access to thenew patient case file by, and contemporaneous communications relating tothe new patient case file between, the first and additional users. 22.The method of claim 21 further comprising: i. returning to the furtheruser, substantially contemporaneous with said access to the new patientcase file, case file information from at least one of the diseaseinformation, image, and patient data tables, in response to searchcriteria related to the new patient case file.
 23. The method of claim22 further comprising: j. providing the new patient case file to areviewer to review the content of the new patient case file, and k.receiving (i) modifications from the reviewer and applying saidmodifications to the new case file and (ii) receiving an approvalindication from the reviewer and in response thereto modifying accessprivileges associated with the new patient case file.
 24. The method ofclaim 18, further comprising: e. receiving a new patient case fileincluding factoid, image and patient data in response to a user input;and f. comparing the new patient case file with other case files, toassist the user in a medical activity relating to the new patient casefile, by: (i) providing selection criteria to the user for searching forfiles having information related to the new patient case file, (ii)processing plural selection criteria received from the user, and (iii)returning to the user case file information substantially matching saidselection criteria.
 25. The method of claim 18, further comprising: e.adding a new case file in response to a user input; f. creating aneducational file by (i) providing selection criteria to the user fordesigning an educational file based in part on the new case file; and(ii) processing selection criterion received from the user, including atleast one of inaccurate information added to or omitted informationwithheld from the educational file, an answer prompt, and a correctanswer to the answer prompt, so as to complete and store the educationalfile; and g. facilitating learning by a further user by (i) presentingthe education file to a further user; (ii) capturing an answer input inresponse to the answer prompt; and (iii) providing the correct answer tothe further user in response to an incorrect answer input.
 26. Themethod of claim 25, wherein step f further comprises creating a sequenceof related educational files, and step g further comprises presenting atleast part of said sequence of related educational files and capturingeach answer input provided in response thereto.
 27. The method of claim26, wherein step g further comprises (i) determining an accuracy levelof said answer inputs, and (ii) determining a next educational file topresent to the further user based in part on said determined accuracylevel.
 28. The method of claim 26, wherein the further user is a medicalstudent and step g further comprises capturing answer inputs by themedical student for each of the sequence of related educational filesand storing a representation of the captured answer inputs forsubsequent use by an educator.
 29. The method of claim 18, furthercomprising: e. accepting user inputs representative of a searchcriterion; and f. returning to the user a list representative of theaccessible case files substantially matching the search criterion. 30.The method of claim 29, wherein the inputs comprise selection of acategory, and step f comprises returning a list of each case file forwhich the search criterion substantially matches data contained in suchcase file's factoid, image and patient data.
 31. The method of claim 29,wherein the inputs comprise user selection of medical information tosearch, and step f comprises returning a list of each case file forwhich the medical information substantially matches data contained insuch case file's factoid, image and patient data.
 32. A method forproviding remotely accessible medical image database information via amedical image database having plural tables, comprising: a. storingplural disease factoid files in a disease information table; b. storingplural image files each comprising at least one of an image and imagecaption information in an image table; c. storing plural patient fileseach comprising at least one of patient information and clinicalinformation in a patient data table; d. operably coupling the diseaseinformation, image, and patient data tables such that an at least onefactoid file, at least one image file and at least one patient file arerelationally linked to each other as a first case file; e. adding a newcase file including factoid, image and patient data to the tables inresponse to a user input and associating a first access privilege withthe new case file; f. providing the new case file to at least onereviewer to review the content of the new case file; and g. receivingfrom the reviewer (i) one or more modifications from the reviewer andapplying said modifications to the new case file, and (ii) an approvalindication and associating a second access privilege with the new casefile.
 33. The method of claim 32, further comprising: h. accepting userinputs representative of a search criterion; and i. returning to theuser a list representative of the accessible case files substantiallymatching the search criterion.
 34. A method for facilitating remoteconsultation by a medical service provider using a medical imagedatabase having plural tables, comprising: a. storing plural diseasefactoid files in a disease information table; b. storing plural imagefiles each comprising at least one of an image and image captioninformation in an image table; c. storing plural patient files eachcomprising at least one of patient information and clinical informationin a patient data table; d. operably coupling the disease information,image, and patient data tables such that an at least one factoid file,at least one image file and at least one patient file are relationallylinked to each other as a first case file; e. adding a new patient casefile including factoid, image and patient data to the tables in responseto a first user's inputs, the inputs also including a criterion foraccessing the patient case file; f. verifying that an additional userhas access privileges matching the criterion for accessing the patientcase file, and providing the new patient case file to the additionaluser to review the content of the patient case file; and g. providingcontemporaneous access to the new patient case file by the first andadditional users.
 35. The method of claim 34 further comprising: h.returning to the further user, substantially contemporaneous with saidaccess to the new patient case file, case file information from at leastone of the disease information, image, and patient data tables, inresponse to search criteria related to the new patient case file.
 36. Amethod A method of facilitating learning by medical professionalsregardless of distance using a medical image database having pluraltables, comprising: a. storing plural disease factoid files in a diseaseinformation table; b. storing plural image files each comprising atleast one of an image and image caption information in an image table;c. storing plural patient files each comprising at least one of patientinformation and clinical information in a patient data table; d.operably coupling the disease information, image, and patient datatables such that an at least one factoid file, at least one image fileand at least one patient file are relationally linked to each other as afirst case file; e. adding a new case file in response to a user input;f. creating an educational file by (i) providing selection criteria tothe user for designing an educational file based in part on the new casefile; and (ii) processing selection criterion received from the user,including at least one of inaccurate information added to or omittedinformation withheld from the educational file, an answer prompt, and acorrect answer to the answer prompt, so as to complete and store theeducational file; and g. facilitating learning by a further user bysubsequently (i) presenting the education file to the further user; (ii)capturing an answer input in response to the answer prompt; and (iii)providing the correct answer to the further user in response to anincorrect answer input.
 37. The method of claim 36, wherein step ffurther comprises creating a sequence of related educational files, andstep g further comprises presenting at least part of said sequence ofrelated educational files and capturing each answer input provided inresponse thereto.
 38. The method of claim 36, wherein step g furthercomprises (i) determining an accuracy level of said answer inputs, and(ii) determining a next educational file to present to the further userbased in part on said determined accuracy level.
 39. The method of claim36, wherein the further user is a medical student and step g furthercomprises capturing answer inputs by the medical student for each of thesequence of related educational files and storing a representation ofthe captured answer inputs for subsequent use by an educator.
 40. Amedical image database system comprising: a. means for storing pluraldisease factoid files in a disease information table; b. means forstoring plural image files each comprising at least one of an image andimage caption information in an image table; c. means for storing pluralpatient files each comprising at least one of patient information andclinical information in a patient data table; d. means for operablycoupling the disease information, image, and patient data tables suchthat an at least one factoid file, at least one image file and at leastone patient file are relationally linked to each other as a first casefile; e. means for adding a new case file including factoid, image andpatient data to the tables in response to a user input and associating afirst access privilege with the new case file; f. means for providingthe new case file to at least one reviewer to review the content of thenew case file; and g. means for receiving from the reviewer (i) one ormore modifications from the reviewer and applying said modifications tothe new case file, and (ii) an approval indication and associating asecond access privilege with the new case file.